[アップデート] Security Hubのセキュリティ標準に『NIST Special Publication 800-53 Revision 5』が追加されました

[アップデート] Security Hubのセキュリティ標準に『NIST Special Publication 800-53 Revision 5』が追加されました

2023年3月17日現在の『NIST Special Publication 800-53 Revision 5』のコントロール数は222で、『AWS基礎セキュリティベストプラクティス』のコントロールを全て内包して構成されており、このセキュリティ標準の追加に合わせて新規のコントロールが10個追加されていました。
Clock Icon2023.03.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさん、こんにちは。

AWS事業本部コンサルティング部の芦沢(@ashi_ssan)です。

AWSのアップデートにより、Security Hubのセキュリティ標準に『NIST Special Publication 800-53 Revision 5』が追加されました。

AWS公式からもWhat’s newブログで発表されています。

はじめに

そもそも「NIST」や「NIST Special Publication 800-53 Revision 5」についてご存知ない方もいると思いますので、初めに3行で簡単に紹介してみます。

  • NISTとはアメリカの政府機関「米国国立標準技術研究所(National Institute of Standards and Technology)」のこと
  • NISTが2014年に発行した重要インフラのサイバーセキュリティを向上させるためのフレームワーク(通称NIST CFT、NIST Cyber Security Framework)の下位概念としてSpecial Publication 800(SP 800)というものがある
  • NIST SP 800はセキュリティマネジメントやリスクマネジメント、セキュリティ技術、セキュリティ対策状況を評価する指標などが幅広く網羅されていて、その下位に位置するSP 800-53は連邦政府機関の機密情報の保護に関する要件が定義されたもの。その資料のRevision 5(バージョン5)。

(参考リンク:NIST発行の情報セキュリティ関連文書(CSFとSP 800の位置づけ)

NIST CFTについては弊社ブログでも紹介されていますので、こちらもあわせてご覧ください。

まずは、追加されたセキュリティ標準『NIST Special Publication 800-53 Revision 5』の詳しい内容を確認していきたいと思います。

セキュリティ標準『NIST Special Publication 800-53 Revision 5』について

アップデートの概要について、What’s newブログを自動翻訳したものの抜粋になりますが、以下のように記載されていました。

Security Hub の NIST SP 800-53 r5 標準には、 36 の AWS サービス全体で 121 の NIST SP 800-53 r5 要件に対して継続的なチェックを実行する最大 224 の自動制御が含まれています。これには、この標準に固有の 10 の新しいセキュリティ コントロールが含まれます。

224個のコントロールが含まれていて、固有の新しいコントロールが10個増えているようですね。

ドキュメント Historyを確認してみた

AWS公式ドキュメントのHistoryから確認したところ、新規のコントロールとして以下の10個のコントロールが追加されたようです。こちらが固有の新しいコントロールのようですね。

個人的に気になるのは[Account.2]でOrganizations利用の要件、DynamoDBやEC2、RDSで”backup plan”に関する要件が追加されているところでしょうか。

SP 800-53がカバーしている機密情報保護要件独自の特徴が伺えます。

AWS基礎セキュリティベストプラクティスと比較してみた

続いて、新規のコントロール以外についてどのようなコントロールが含まれているのか気になったので、他のセキュリティ標準(『AWS基礎セキュリティベストプラクティス』)と比較してみました。

比較するにあたって利用したコントロールの一覧は以下のAWS公式ドキュメント(英語版)です。

比較結果をまとめた表がこちらです。

コントロール名 NIST SP800-53 AWS基礎セキュリティベストプラクティス
[Account.1] Security contact information should be provided for an AWS account.
[Account.2] AWS accounts should be part of an AWS Organizations organization -
[ACM.1] Imported and ACM-issued certificates should be renewed after a specified time period
[APIGateway.1] API Gateway REST and WebSocket API execution logging should be enabled
[APIGateway.2] API Gateway REST API stages should be configured to use SSL certificates for backend authentication
[APIGateway.3] API Gateway REST API stages should have AWS X-Ray tracing enabled
[APIGateway.4] API Gateway should be associated with a WAF Web ACL
[APIGateway.5] API Gateway REST API cache data should be encrypted at rest
[APIGateway.8] API Gateway routes should specify an authorization type
[APIGateway.9] Access logging should be configured for API Gateway V2 Stages
[AutoScaling.1] Auto Scaling groups associated with a Classic Load Balancer should use load balancer health checks
[AutoScaling.2] Amazon Amazon EC2 Auto Scaling group should cover multiple Availability Zones
[AutoScaling.3] Auto Scaling group launch AWS Configurations should AWS Configure Amazon EC2 instances to require Instance Metadata Service Version 2 (IMDSv2)
[AutoScaling.4] Auto Scaling group launch AWS Configuration should not have a metadata response hop limit greater than 1
[Autoscaling.5] Amazon Amazon EC2 instances launched using Auto Scaling group launch AWS Configurations should not have Public IP addresses
[AutoScaling.6] Auto Scaling groups should use multiple instance types in multiple Availability Zones
[AutoScaling.9] Amazon EC2 Auto Scaling groups should use Amazon EC2 launch templates
[CloudFormation.1] CloudFormation stacks should be integrated with Simple Notification Service (SNS)
[CloudFront.1] CloudFront distributions should have a default root object configured
[CloudFront.2] CloudFront distributions should have origin access identity enabled
[CloudFront.3] CloudFront distributions should require encryption in transit
[CloudFront.4] CloudFront distributions should have origin failover configured
[CloudFront.5] CloudFront distributions should have logging enabled
[CloudFront.6] CloudFront distributions should have WAF enabled
[CloudFront.7] CloudFront distributions should use custom SSL/TLS certificates
[CloudFront.8] CloudFront distributions should use SNI to serve HTTPS requests
[CloudFront.9] CloudFront distributions should encrypt traffic to custom origins
[CloudFront.10] CloudFront distributions should not use deprecated SSL protocols between edge locations and custom origins
[CloudFront.12] CloudFront distributions should not point to non-existent S3 origins
[CloudTrail.1] CloudTrail should be enabled and configured with at least one multi-Region trail that includes read and write management events
[CloudTrail.2] CloudTrail should have encryption at-rest enabled
[CloudTrail.4] CloudTrail log file validation should be enabled
[CloudTrail.5] CloudTrail trails should be integrated with Amazon CloudWatch Logs
[CloudWatch.15] CloudWatch alarms should have an action configured for the ALARM state -
[CloudWatch.16] CloudWatch log groups should be retained for at least 1 year -
[CloudWatch.17] CloudWatch alarm actions should be activated -
[CodeBuild.1] CodeBuild GitHub or Bitbucket source repository URLs should use OAuth
[CodeBuild.2] CodeBuild project environment variables should not contain clear text credentials
[CodeBuild.3] CodeBuild S3 logs should be encrypted
[CodeBuild.4] CodeBuild project environments should have a logging AWS Configuration
[CodeBuild.5] CodeBuild project environments should not have privileged mode enabled
[Config.1] AWS Config should be enabled
[DMS.1] Database Migration Service replication instances should not be public
[DynamoDB.1] DynamoDB tables should automatically scale capacity with demand
[DynamoDB.2] DynamoDB tables should have point-in-time recovery enabled
[DynamoDB.3] DynamoDB Accelerator (DAX) clusters should be encrypted at rest
[DynamoDB.4] DynamoDB tables should be covered by a backup plan -
[EC2.1] Amazon EBS snapshots should not be publicly restorable
[EC2.2] The VPC default security group should not allow inbound and outbound traffic
[EC2.3] Attached Amazon EBS volumes should be encrypted at-rest
[EC2.4] Stopped Amazon EC2 instances should be removed after a specified time period
[EC2.6] VPC flow logging should be enabled in all VPCs
[EC2.7] Amazon EBS default encryption should be enabled
[EC2.8] Amazon EC2 instances should use Instance Metadata Service Version 2 (IMDSv2)
[EC2.9] Amazon EC2 instances should not have a public IPv4 address
[EC2.10] Amazon EC2 should be configured to use VPC endpoints that are created for the Amazon EC2 service
[EC2.12] Unused Amazon EC2 EIPs should be removed -
[EC2.13] Security groups should not allow ingress from 0.0.0.0/0 to port 22 -
[EC2.15] Amazon EC2 subnets should not automatically assign public IP addresses
[EC2.16] Unused Network Access Control Lists should be removed
[EC2.17] Amazon EC2 instances should not use multiple ENIs
[EC2.18] Security groups should only allow unrestricted incoming traffic for authorized ports
[EC2.19] Security groups should not allow unrestricted access to ports with high risk
[EC2.20] Both VPN tunnels for an AWS Site-to-Site VPN connection should be up
[EC2.21] Network ACLs should not allow ingress from 0.0.0.0/0 to port 22 or port 3389
[EC2.22] Unused Amazon EC2 security groups should be removed
[EC2.23] Amazon EC2 Transit Gateways should not automatically accept VPC attachment requests
[EC2.24] Amazon EC2 paravirtual instance types should not be used
[EC2.25] Amazon EC2 launch templates should not assign public IPs to network interfaces
[EC2.28] EBS volumes should be covered by a backup plan -
[EC2.29] EC2 instances should be launched in a VPC -
[ECR.1] ECR private repositories should have image scanning configured
[ECR.2] ECR private repositories should have tag immutability configured
[ECR.3] ECR repositories should have at least one lifecycle policy configured
[ECS.1] Amazon ECS task definitions should have secure networking modes and user definitions.
[ECS.2] ECS services should not have public IP addresses assigned to them automatically
[ECS.3] ECS task definitions should not share the host's process namespace
[ECS.4] ECS containers should run as non-privileged
[ECS.5] ECS containers should be limited to read-only access to root filesystems
[ECS.8] Secrets should not be passed as container environment variables
[ECS.10] ECS Fargate services should run on the latest Fargate platform version
[ECS.12] ECS clusters should use Container Insights
[EFS.1] Elastic File System should be configured to encrypt file data at-rest using AWS KMS
[EFS.2] Amazon EFS volumes should be in backup plans
[EFS.3] EFS access points should enforce a root directory
[EFS.4] EFS access points should enforce a user identity
[EKS.2] EKS clusters should run on a supported Kubernetes version
[ElastiCache.1] ElastiCache for Redis clusters should have automatic backups scheduled
[ElastiCache.2] Minor version upgrades should be automatically applied to ElastiCache for Redis cache clusters
[ElastiCache.3] ElastiCache for Redis replication groups should have automatic failover enabled
[ElastiCache.4] ElastiCache for Redis replication groups should be encrypted at rest
[ElastiCache.5] ElastiCache for Redis replication groups should be encrypted in transit
[ElastiCache.6] ElastiCache for Redis replication groups before version 6.0 should use Redis AUTH
[ElastiCache.7] ElastiCache clusters should not use the default subnet group
[ElasticBeanstalk.1] Elastic Beanstalk environments should have enhanced health reporting enabled
[ElasticBeanstalk.2] Elastic Beanstalk managed platform updates should be enabled
[ELB.1] Application Load Balancer should be configured to redirect all HTTP requests to HTTPS
[ELB.2] Classic Load Balancers with SSL/HTTPS listeners should use a certificate provided by AWS Certificate Manager
[ELB.3] Classic Load Balancer listeners should be configured with HTTPS or TLS termination
[ELB.4] Application Load Balancer should be configured to drop http headers
[ELB.5] Application and Classic Load Balancers logging should be enabled
[ELB.6] Application Load Balancer deletion protection should be enabled
[ELB.7] Classic Load Balancers should have connection draining enabled
[ELB.8] Classic Load Balancers with SSL listeners should use a predefined security policy that has strong AWS Configuration
[ELB.9] Classic Load Balancers should have cross-zone load balancing enabled
[ELB.10] Classic Load Balancer should span multiple Availability Zones
[ELB.12] Application Load Balancer should be configured with defensive or strictest desync mitigation mode
[ELB.13] Application, Network and Gateway Load Balancers should span multiple Availability Zones
[ELB.14] Classic Load Balancer should be configured with defensive or strictest desync mitigation mode
[EMR.1] Amazon Elastic MapReduce cluster master nodes should not have public IP addresses
[ES.1] Elasticsearch domains should have encryption at-rest enabled
[ES.2] Elasticsearch domains should be in a VPC
[ES.3] Elasticsearch domains should encrypt data sent between nodes
[ES.4] Elasticsearch domain error logging to CloudWatch Logs should be enabled
[ES.5] Elasticsearch domains should have audit logging enabled
[ES.6] Elasticsearch domains should have at least three data nodes
[ES.7] Elasticsearch domains should be configured with at least three dedicated master nodes
[ES.8] Connections to Elasticsearch domains should be encrypted using TLS 1.2
[GuardDuty.1] GuardDuty should be enabled
[IAM.1] IAM policies should not allow full "*" administrative privileges
[IAM.2] IAM users should not have IAM policies attached
[IAM.3] IAM users' access keys should be rotated every 90 days or less
[IAM.4] IAM root user access key should not exist
[IAM.5] MFA should be enabled for all IAM users that have a console password
[IAM.6] Hardware MFA should be enabled for the root user
[IAM.7] Password policies for IAM users should have strong AWS Configurations
[IAM.8] Unused IAM user credentials should be removed
[IAM.9] Virtual MFA should be enabled for the root user -
[IAM.19] MFA should be enabled for all IAM users -
[IAM.21] IAM customer managed policies that you create should not allow wildcard actions for services
[Kinesis.1] Kinesis streams should be encrypted at rest
[KMS.1] IAM customer managed policies should not allow decryption actions on all KMS keys
[KMS.2] IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys
[KMS.3] AWS KMS keys should not be deleted unintentionally
[KMS.4] AWS KMS key rotation should be enabled -
[Lambda.1] Lambda function policies should prohibit public access
[Lambda.2] Lambda functions should use supported runtimes
[Lambda.3] Lambda functions should be in a VPC -
[Lambda.5] VPC Lambda functions should operate in more than one Availability Zone
[NetworkFirewall.3] Network Firewall policies should have at least one rule group associated
[NetworkFirewall.4] The default stateless action for Network Firewall policies should be drop or forward for full packets
[NetworkFirewall.5] The default stateless action for Network Firewall policies should be drop or forward for fragmented packets
[NetworkFirewall.6] Stateless Network Firewall rule group should not be empty
[Opensearch.1] OpenSearch domains should have encryption at rest enabled
[Opensearch.2] OpenSearch domains should be in a VPC
[Opensearch.3] OpenSearch domains should encrypt data sent between nodes
[Opensearch.4] OpenSearch domain error logging to CloudWatch Logs should be enabled
[Opensearch.5] OpenSearch domains should have audit logging enabled
[Opensearch.6] OpenSearch domains should have at least three data nodes
[Opensearch.7] OpenSearch domains should have fine-grained access control enabled
[Opensearch.8] Connections to OpenSearch domains should be encrypted using TLS 1.2
[RDS.1] RDS snapshot should be private
[RDS.2] RDS DB Instances should prohibit public access, as determined by the PubliclyAccessible AWS Configuration
[RDS.3] RDS DB instances should have encryption at-rest enabled
[RDS.4] RDS cluster snapshots and database snapshots should be encrypted at rest
[RDS.5] RDS DB instances should be configured with multiple Availability Zones
[RDS.6] Enhanced monitoring should be configured for RDS DB instances
[RDS.7] RDS clusters should have deletion protection enabled
[RDS.8] RDS DB instances should have deletion protection enabled
[RDS.9] Database logging should be enabled
[RDS.10] IAM authentication should be configured for RDS instances
[RDS.11] RDS instances should have automatic backups enabled
[RDS.12] IAM authentication should be configured for RDS clusters
[RDS.13] RDS automatic minor version upgrades should be enabled
[RDS.14] Amazon Aurora clusters should have backtracking enabled
[RDS.15] RDS DB clusters should be configured for multiple Availability Zones
[RDS.16] RDS DB clusters should be configured to copy tags to snapshots
[RDS.17] RDS DB instances should be configured to copy tags to snapshots
[RDS.18] RDS instances should be deployed in a VPC
[RDS.19] An RDS event notifications subscription should be configured for critical cluster events
[RDS.20] An RDS event notifications subscription should be configured for critical database instance events
[RDS.21] An RDS event notifications subscription should be configured for critical database parameter group events
[RDS.22] An RDS event notifications subscription should be configured for critical database security group events
[RDS.23] RDS instances should not use a database engine default port
[RDS.24] RDS Database clusters should use a custom administrator username
[RDS.25] RDS database instances should use a custom administrator username
[RDS.26] RDS DB instances should be covered by a backup plan -
[Redshift.1] Amazon Redshift clusters should prohibit public access
[Redshift.2] Connections to Amazon Redshift clusters should be encrypted in transit
[Redshift.3] Amazon Redshift clusters should have automatic snapshots enabled
[Redshift.4] Amazon Redshift clusters should have audit logging enabled
[Redshift.6] Amazon Redshift should have automatic upgrades to major versions enabled
[Redshift.7] Redshift clusters should use enhanced VPC routing
[Redshift.8] Amazon Redshift clusters should not use the default Admin username
[Redshift.9] Redshift clusters should not use the default database name
[S3.1] S3 Block Public Access setting should be enabled
[S3.2] S3 buckets should prohibit public read access
[S3.3] S3 buckets should prohibit public write access
[S3.4] S3 buckets should have server-side encryption enabled
[S3.5] S3 buckets should require requests to use Secure Socket Layer
[S3.6] S3 permissions granted to other AWS accounts in bucket policies should be restricted
[S3.7] S3 buckets should have cross-Region replication enabled -
[S3.8] S3 Block Public Access setting should be enabled at the bucket-level
[S3.9] S3 bucket server access logging should be enabled
[S3.10] S3 buckets with versioning enabled should have lifecycle policies configured
[S3.11] S3 buckets should have event notifications enabled
[S3.12] S3 access control lists (ACLs) should not be used to manage user access to buckets
[S3.13] S3 buckets should have lifecycle policies configured
[S3.14] S3 buckets should use versioning -
[SageMaker.1] Amazon SageMaker notebook instances should not have direct internet access
[SageMaker.2] SageMaker notebook instances should be launched in a custom VPC
[SageMaker.3] Users should not have root access to SageMaker notebook instances
[SecretsManager.1] Secrets Manager secrets should have automatic rotation enabled
[SecretsManager.2] Secrets Manager secrets configured with automatic rotation should rotate successfully
[SecretsManager.3] Remove unused Secrets Manager secrets
[SecretsManager.4] Secrets Manager secrets should be rotated within a specified number of days
[SNS.1] SNS topics should be encrypted at-rest using AWS KMS
[SNS.2] Logging of delivery status should be enabled for notification messages sent to a topic
[SQS.1] Amazon SQS queues should be encrypted at rest
[SSM.1] Amazon EC2 instances should be managed by AWS Systems Manager
[SSM.2] Amazon EC2 instances managed by Systems Manager should have a patch compliance status of COMPLIANT after a patch installation
[SSM.3] Amazon EC2 instances managed by Systems Manager should have an association compliance status of COMPLIANT
[SSM.4] SSM documents should not be public
[WAF.1] AWS WAF Classic Global Web ACL logging should be enabled
[WAF.2] A WAF Regional rule should have at least one condition
[WAF.3] A WAF Regional rule group should have at least one rule
[WAF.4] A WAF Regional web ACL should have at least one rule or rule group
[WAF.6] A WAF global rule should have at least one condition
[WAF.7] A WAF global rule group should have at least one rule
[WAF.8] A WAF global web ACL should have at least one rule or rule group
[WAF.10] A WAFV2 web ACL should have at least one rule or rule group
[WAF.11] AWS WAFv2 web ACL logging should be activated -

表をよくみていただくとわかるように2023年3月現在の時点では『AWS基礎セキュリティベストプラクティス』にあるControl IDは、全て『NIST SP800-53 r5』に含まれています。

そして、NISTの合計のコントロール数は222個でした。What's newブログでは最大224個と謳われていたので、サイレント更新があっていくつかのコントロールが退役してしまったのかも?と想像しています(Security HubのドキュメントHistoryとWhat's newブログには少しタイムラグがあったため)


ちなみに、『NIST SP800-53 r5』にあって『AWS基礎セキュリティベストプラクティス』にないコントロールは以下の通りです。有効化を検討されてる方は参考にしてください。

  • [Account.1] Security contact information should be provided for an AWS account.
  • [Account.2] AWS accounts should be part of an AWS Organizations organization
  • [CloudWatch.15] CloudWatch alarms should have an action configured for the ALARM state
  • [CloudWatch.16] CloudWatch log groups should be retained for at least 1 year
  • [CloudWatch.17] CloudWatch alarm actions should be activated
  • [DynamoDB.4] DynamoDB tables should be covered by a backup plan
  • [EC2.12] Unused Amazon EC2 EIPs should be removed
  • [EC2.13] Security groups should not allow ingress from 0.0.0.0/0 to port 22
  • [EC2.28] EBS volumes should be covered by a backup plan
  • [EC2.29] EC2 instances should be launched in a VPC
  • [IAM.9] Virtual MFA should be enabled for the root user
  • [IAM.19] MFA should be enabled for all IAM users
  • [KMS.4] AWS KMS key rotation should be enabled
  • [Lambda.3] Lambda functions should be in a VPC
  • [RDS.26] RDS DB instances should be covered by a backup plan
  • [S3.7] S3 buckets should have cross-Region replication enabled
  • [S3.14] S3 buckets should use versioning
  • [WAF.11] AWS WAFv2 web ACL logging should be activated

有効化してみた

それでは実際のAWS環境でセキュリティ標準を有効化してみましょう。

Security Hubコンソールの「セキュリティ標準」に『NIST Special Publication 800-53 Revision 5』が追加されていますので有効化していきます。

有効化できました。

私の環境では合計のコントロール数が「222」と表示されています。ドキュメントのコントロール数と一致していました。

検証は以上になります。

最後に

本記事では、Security Hubに新しく追加されたセキュリティ標準『NIST Special Publication 800-53 Revision 5』について調べてみました。

Security Hubには、これまでも『CIS AWS Foundations Benchmark v1.2.0/v1.4.0』や『PCI DSS v3.2.1』のAWSベスプラとは別のフレームワークに調整されたコントロールがありました。

『NIST Special Publication 800-53 Revision 5』は、CISやPCI DSSと比べると単純にコントロール数が多く、『AWS基礎セキュリティベストプラクティス』に近いコントロールで構成されていました。

Security Hub、今後もセキュリティ標準が増えていきそうですね。またアップデートがあったらキャッチアップしていきます。

本記事の執筆内容があなたの参考になれば幸いです。

以上、AWS事業本部コンサルティング部の芦沢(@ashi_ssan)でした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.